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Abstract 

The Optiplan planning system is the first integer programming-based planner that 
successfully participated in the international planning competition. This engineering note 
describes the architecture of Optiplan and provides the integer programming formulation 
that enabled it to perform reasonably well in the competition. We also touch upon some 
recent developments that make integer programming encodings significantly more compet- 
itive. 

1. Introduction 

Optiplan is a planning system that uses integer linear programming (IP) to solve STRIPS 
planning problems. It is the first such system to take part in the international planning 
competition (IPC) and was judged the second best performer in four competition domains 
of the optimal track for propositional domains. Optiplan's underlying integer programming 
formulation extends the state change model by Vossen and his colleagues (1999). Its archi- 
tecture is very similar to that of Blackbox (Kautz & Selman, 1999) and GP-CSP (Do & 
Kambhampati, 2001), but instead of unifying satisfiability (SAT) or constraint satisfaction 
(CSP) with graph based planning, Optiplan uses integer programming. Like Blackbox and 
GP-CSP, Optiplan works in two phases. In the first phase a planning graph is built and 
transformed into an IP formulation, then in the second phase the IP formulation is solved 
using the commercial solver ILOG CPLEX (ILOG Inc., 2002). 

A practical difference between the original state change model and Optiplan is that the 
former takes as input all ground actions and fluents over all initialized plan steps, while 
the latter takes as input just those actions and fluents that are instantiated by Graphplan 
(Blum & Furst, 1995). It is well known that the use of planning graphs has a significant 
effect on the size of the final encoding no matter what combinatorial transformation method 
(IP, SAT, or CSP) is used. For instance, Kautz and Selman (1999) as well as Kambhampati 
(1997) pointed out that Blackbox's success over Satplan (Kautz & Selman, 1992) was mainly 
explained by Graphplan's ability to produce better, more refined, propositional structures 
than Satplan. In addition, Optiplan allows propositions to be deleted without being required 
as preconditions. Such state changes are not modeled in the original state change model, and 
therefore Optiplan can be considered to be a more general encoding. One more, although 

©2005 AI Access Foundation. All rights reserved. 



Van den Briel, & Kambhampati 



minor, implementation detail between Optiplan and the state change model is that Optiplan 
reads in PDDL files. 

This engineering note is organized as follows. Section 2 provides a brief background on 
integer programming and Section 3 discusses previous IP approaches to planning. Section 
4 describes the Optiplan planning system and its underlying IP formulation. In Section 5 
we give some experimental results and look at Optiplan's performance in the international 
planning competition of 2004 (IPC4). Conclusions and a brief discussion on some recent 
developments is given in Section 6. 

2. Background 

A linear program is represented by a linear objective function and a set of inequalities, such 
as min{cx : Ax > b, x > 0} where x an n-dimensional column vector of variables, A is an 
m by n matrix, c an n-dimensional row vector, and b an m-dimensional column vector. If 
all variables are constrained to be integers then we have an integer (linear) program, and if 
all variables are restricted to 0-1 values then we have a binary integer program. 

The most widely used method for solving general integer programs is by using branch 
and bound on the linear programming relaxation. Branch and bound is a general search 
method in which subproblems are created that restrict the range of the integer variables, 
and the linear programming relaxation is a linear program obtained from the original integer 
program by omitting the integrality constraints. An ideal formulation of an integer program 
is one for which the solution of the linear programming relaxation is integral. Even though 
every integer program has an ideal formulation (Wolsey, 1998), in practice it is very hard to 
characterize the ideal formulation as it may require an exponential number of inequalities. 
In problems where the ideal formulation cannot be determined, it is often desirable to find 
a strong formulation of the integer program. Suppose that Pi = minjcx : A\x > bi,x > 0} 
and P2 = minjcx : A2X > 62, x > 0} are the linear programming relaxations of two IP 
formulations of a problem, then we say that formulation Pi is stronger than formulation P2 
if Pi C Pi. That is, the set of solutions of Pi is subsumed by the set of solutions of Pi. 

3. Integer Programming Approaches to Planning 

Despite the vast amount of research that has been conducted in the field of AI planning, the 
use of linear programming (LP) and integer linear programming have only been explored at 
a marginal level. This is quite surprising since (mixed) integer linear programming provide 
feasible environments for using numeric constraints and arbitrary linear objective functions, 
two important aspects in real-world planning problems. 

Only a handful of works have explored the use of LP and IP techniques in AI planning. 
Bylander (1997) developed an IP formulation for classical planning and used the LP relax- 
ation as a heuristic for partial order planning. The results, however, do not seem to scale 
well compared to planning graph and satisfiability based planners. 

The difficulty in developing strong IP formulations is that the performance often de- 
pends on the way the IP formulation is constructed. Vossen et al. (1999) compared two 
formulations for classical planning. First, they consider a straightforward IP formulation 
based on converting the propositional representation given by Satplan (Kautz & Selman, 
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1992) to an IP formulation with variables that take the value 1 if a certain proposition 
is true, and otherwise. In this formulation, the assertions expressed by IP constraints 
directly correspond to the logical conditions of the propositional representation. Second, 
they consider an IP formulation in which the original propositional variables are replaced 
by state change variables. State change variables take the value 1 if a certain proposition is 
added, deleted, or persisted, and otherwise. Vossen et al. show that the formulation based 
on state change variables outperforms the straightforward formulation based on converting 
the propositional representation. 

Dimopoulos (2001) improves the IP formulation based on state change variables by iden- 
tifying valid inequalities that tighten the formulation. Yet, even stronger IP formulations 
are given by Bockmayr and Dimopoulos (1998, 1999), but their IP formulations contain 
domain dependent knowledge and are, therefore, limited to solving problems of specific 
problem domains only. 

LP and IP techniques have also been explored for non-classical planning. Dimopoulos 
and Gerevini (2002) describe a mixed integer programming formulation for temporal plan- 
ning and Wolfman and Weld (1999) use an LP formulation in combination with a SAT 
formulation to solve resource planning problems. Kautz and Walser (1999) also use IP 
formulations for resource planning problems but, in addition, incorporate action costs and 
complex objectives. 

So far, none of these IP approaches to AI planning ever participated in the IPC, making 
it harder to assess the relative effectiveness of this line of work. Optiplan, a planner based 
on the state change formulation, is the first IP-based planner to do so. 

4. Optiplan 

Optiplan is a planning graph based planner and works as follows. First we build the 
planning graph to the level where all the goal fluents appear non-mutex. Then we compile 
the planning graph into an integer program and solve it. If no plan is found, the planning 
graph is extended by one level and the new graph is again compiled into an integer program 
and solved again. This process is repeated until a plan is found. 

In the remainder of this section we give the IP formulation that is used by Optiplan. In 
order to present the IP formulation we will use the following notation. T is the set of fluents 
and A is the set of actions (operators). The fluents that are true in the initial state and 
the fluents that must be true in the goal are given by X and Q respectively. Furthermore, 
we will use the sets: 

• pref C A, V/ G JF, set of actions that have fluent / as precondition; 

• addf C A, V/ £ T, set of actions that have fluent / as add effect; 

• delf C A, V/ € J 7 , set of actions that have fluent / as delete effect; 

Variables are defined for each layer 1 < t < T in the planning graph. There are 
variables for the actions and there are variables for the possible state changes a fluent can 
make, but only those variables that are reachable and relevant by planning graph analysis 
are instantiated. For all a € A, t G 1, ...,T we have the action variables 
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y a ,t 



1 if action a is executed in period t, 
otherwise. 



The "no-op" actions are not included in the y at t variables but are represented separately 
by the state change variable x J l ^ mtam . 

Optiplan is based on the state change formulation (Vossen et al., 1999). In this formula- 
tion fluents are not represented explicitly, instead state change variables are used to model 
transitions in the world state. That is, a fluent is true if and only if it is added to the state by 
x add Qr rj$jz add ^ or ^ \i j s persisted from the previous state by x ^ intain . Optiplan extends 
the state change formulation (Vossen et al., 1999) by introducing an extra state change 
variable, x de \, that allows actions to delete fluents without requiring them as preconditions. 
The original state change formulation did not allow for these actions, so therefore we added 
these new state change variables to keep track of such state changes and altered the model 
to take these new variables into account. In the IPC4 domains of Airport and PSR there are 
many actions that delete fluents without requiring them as preconditions, therefore making 
the original state change formulation ineffective. Also, Optiplan instantiates only those 
variables and constraints that are reachable and relevant through planning graph analysis, 
and therefore creates a smaller encoding than the original one. For all / € T , t € 1, ...,T 
we have the following state change variables: 

^.maintain = f 1 if fluent / is propagated in period t, 
ft \ otherwise. 

preadd _ / 1 if action a is executed in period t such that a G pref A a ^ delf, 



fJ I otherwise. 



predei _ / 1 if action a is executed in period t such that a £ pref A a € delf, 



X f< f 1 otherwise. 



add _ / 1 if action a is executed in period t such that a pref A a € addf, 



X f' 1 1 otherwise 



del _ { 1 if action a is executed in period £such that a £ pref A a € delf, 



X f' t \ otherwise. 

In summary: xj^ mtam = 1 if the truth value of a fluent is propagated; x p ^ add = 1 if an 
action is executed that requires a fluent and does not delete it; x p ^ del = 1 if an action is 
executed that requires a fluent and deletes it; xj d f = 1 if an action is executed that does 
not require a fluent and adds it; and x d ^ e \ = 1 if an action is executed that does not require 
a fluent and deletes it. The complete IP formulation of Optiplan is given by the following 
objective function and constraints. 



4.1 Objective 

For classical Al planning problems, no minimization or maximization is required, instead 
we want to find a feasible solution. The search for a solution, however, may be guided by 
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an objective function such as the minimization of the number of actions, which is currently 
implemented in Optiplan. The objective function is given by: 



Since the constraints guarantee feasibility we could have used any linear objective func- 
tion. For example, we could easily set up an objective to deal with cost-sensitive plans 
(in the context of non-uniform action cost), utility-sensitive plans (in the context of over- 
subscription and goal utilities), or any other metric that can be transformed to a linear 
expression. Indeed this flexibility to handle any linear objective function is one of the ad- 
vantages of IP formulations. 



4.2 Constraints 

The requirements on the initial and goal transition are given by: 



add 

x ffi 


= 1 


V/el 


(2) 


^add maintain preadd 
x /,0' X /,0 ' X /,0 


= 


\/f^l 


(3) 


„add | ^maintain , preadd 
X f,T ~r x f,T ' x f T 


> 1 




(4) 



Where constraints (2), and (3) add the initial fluents in step so that they can be used 
by the actions that appear in the first layer (step 1) of the planning graph. Constraints 
(4) represent the goal state requirements, that is, fluents that appear in the goal must be 
added or propagated in step T. 

The state change variables are linked to the actions by the following effect implication 
constraints. For each / G T and 1 < t < T we have: 



E ^ x lf 

a€addf\pref 




(5) 


Va,t < X a ff 


Va G add/ \ pref 


(6) 


E KM ^ x tl 
a(zdelf\pref 




(7) 


Va,t < xfl 


Va G del / \ pre f 


(8) 


\ ^ preadd 

E v°t ^ x u 

a€pref\delf 




(9) 


^ preadd 
Va,t < Xf, t 


Va G pre / \ del / 


(10) 


\ predel 




(11) 



aGprefAdel f 



Where constraints (5) to (11) represent the logical relations between the action and 
state change variables. The equality sign in (11) is because all actions that have / as a 
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precondition and as a delete effect are mutually exclusive. This also means that we can 
substitute out the x p ^ del variables, which is what we have done in the implementation of 
Optiplan. We will, however, use the variables here for clarity. Mutexes also appear between 
different state change variables and these are expressed by constraints as follows: 



add r maintain , del , predel ^ -. 

/,< fit X f,t ' X f,t — 1 

preadd , maintain , del , ^predel ^ -. 

U f,t f,t + x f,t — 1 



(12) 
(13) 



Where constraints (12) and (13) restrict certain state changes from occurring in parallel. 



^maintain 



(propagating fluent / at step t) is mutually exclusive with x 



add ^del 
X i 



f,t ' */,t 



For example, x r j t 

predel 

Finally, the backward chaining requirements and binary constraints are represented by: 



and ar^' t eue ' (adding or deleting / at t) 



x 



preadd 



+ X 



maintain 
U 



i ^predel ^ u, cuu,u, . aaa , imnu 
-t- Xj t ^ X f,t-1 ' X f,t-1 + X f,t-1 



preadd 



add 



.maintain 



V/€f,tel,..,T (14) 



preadd predel add del maintain ^r n i\ 

C f,t > X f,t 1 X f,t l X f,tl X f,t fc l U ! L J 



Va,t G{0, 1} 



(15) 
(16) 



Where constraints (14) describe the backward chaining requirements, that is, if a fluent 
/ is added or maintained in step t—\ then the state of / can be changed by an action in step 
t through x p ^ add ', or x v J^ del , or it can be propagated through x 1 J l ^ mtam . Constraints (15) 
and (16) are the binary constraints for the state change and action variables respectively. 



Loci 



Loc2 



Truckl 



kl I Truck2 ' 




Figure 1: A simple logistics example 



4.3 Example 

In this example, we show how some of the constraints are initialized and we comment on 
the interaction between the state change variables and the action variables. 

Consider a simple logistics example in which there are two locations, two trucks, and 
one package. The package can only be transported from one location to another by one of 
the trucks. We built a formulation for three plan steps. The initial state is that the package 
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and the trucks are all at location 1 as given in Figure 1. The initial state constraints are: 

add _ -i 

x packl_at_locl,0 — L 

add _ -i 

x truckl_atJocl,0 ~~ L 

add _ -i 

x truck2_at_locl,0 — L 

^add maintain preadd n f _l t 

x /,0' X /,0 ' /,0 ~~ U J ' - L 

The goal is to get the package at location 2 in three plan steps, which is expressed as 
follows: 

^add , maintain . preadd ~ -. 

x packl_at_loc2,3 "•" x packl_at_loc2,3 "•" x packl_at_loc2,3 — 1 

We will not write out all effect implication constraints, but we will comment on a few 
of them. If x°j d t = 1 for a certain fluent /, then we have to execute at least one action a 
that has / as an add effect and not as a precondition. For example: 

2/unload_truckl_at_loc2,t H - £/unload_truck2_at_loc2,t ^ x packl_at_loc2,t 

The state changes for x d ^\ and x p ^ add have a similar requirement, that is if we change 
the state through del or preadd then we must execute at least one action a with the cor- 
responding effects. On the other hand, if we execute an action a then we must change all 
fluent states according to the effects of a. For example: 

i/unload_truckl_at_loc2,t x packl_at_loc2,t 

preadd 

yunload_truckl_at_loc2,t S x truck_at_loc2,t 

_ predel 

2/unload_truckl_atJoc2,t — z pa ckl_in_truckl,t 

There is a one-to-one correspondence (note the equality sign) between the execution of 
actions and the x p ^ del state change variables. This is because, actions that have the same 
predel effect must be mutex. Mutexes are also present between state changes. For example, 
a fluent / that is maintained (propagated) cannot be added or deleted. The only two state 
changes that are not mutex are the add and the preadd. This is because the add state 
change behaves like the preadd state change if the corresponding fluent is already present 
in the state of the world. This is why we introduce two separate mutex constraints, one 
that includes the add state change and one that includes the preadd. An example for the 
constraints on the mutex state changes are as follows: 

add , maintain , del , predel ^ -. 

x packl_in_truckl,t "•" x packl_in_truckl,t ~r x packl_in_truckl,t ~r •*'packl_in_truckl,t — 

preadd , maintain , del , predel ^ -, 

x packl_in_truckl,t x packl_in_truckl,t x packl_in_truckl,t "•" x packl_in_truckl,t — 1 

The state of a fluent can change into another state only if correct state changes have 
occurred previously. Hence, a fluent can be deleted, propagated, or used as preconditions 
in step t if and only if it was added or propagated in step t — 1. For example: 

preadd , maintain , predel < - 

X packl_in_truckl,t ~r x packl_in_truckl,t X packl_in_truckl,t — 

preadd . add , maintain 

X packl_in_truckl,t-1 ~ l ~ x packl_in_truckl,t-l x packl_in_truckl,t-l 
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t = 


t = 1 


t = 2 


t = 3 


^add 

x packl_at_locl,0 

~,add 

x truckl_at_locl,0 

^add 

x truck2_at_locl,0 


yioad_truckl_at_locl,l 
^add 

packl_in_truckl,l 

predel 
"^pack 1 _at _lo c 1 , 1 

preadd 
X truckl_at_locl,l 

^maintain 
x truck2_at_locl,l 


2/drive_truckl_locl_loc2,2 

maintain 
x packl _in_truckl ,2 

~,add 

x truckl_at_loc2,2 

predel 
X truckl_at_locl,2 


yunload_truckl_at_loc2,3 

^add 

x packl_at_loc2,3 

predel 
■^■packl_in_truckl,3 

preadd 
X truckl_at_loc2,3 



Table 1: Solution to the simple logistics example. All displayed variables have value 1 and 
all other variables have value 0. 



This simple problem has a total of 107 variables (41 action and 66 state change) and 
91 constraints. However, planning graph analysis fixes 53 variables (28 action and 25 state 
change) to zero. After substituting these values and applying presolve techniques that are 
built in the ILOG CPLEX solver, this problem has only 13 variables and 17 constraints. 
The solution for this example is given in Table 1. Note that, when there are no actions 
that actively delete /, there is nothing that ensures x 1 J1 mtam to be true whenever / was 
true in the preceding state (for example, see the fluent truck2_at_locl). Since negative 
preconditions are not allowed, having the option of letting x 'J l ^ mtam be false when it should 
have been true cannot cause actions to become executable when they should not be. We 
will not miss any solutions because constraints (4) ensure that the goal fluents are satisfied, 
therefore forcing x 1 J l ^ mtam to be true whenever this helps us generate a plan. 



5. Experimental Results 

First we compare Optiplan with the original state change model, and then we check how 
Optiplan performed in the IPC of 2004. 

Optiplan and the original state change formulation are implemented in two different 
languages. Optiplan is implemented in C++ using Concert Technology, which is a set of 
libraries that allow you to embed ILOG CPLEX optimizers (ILOG Inc., 2002), and the 
original state change model is implemented in AMPL (Fourer, Gay, k, Kernighan, 1993), 
which is a modeling language for mathematical programming. In order to compare the 
formulations that are produced by these two implementations, they are written to an output 
file using the MPS format. MPS is a standard data format that is often used for transferring 
linear and integer linear programming problems between different applications. Once the 
MPS file, which contains the IP formulation for the planning problem, is written, it is read 
and solved by ILOG CPLEX 8.1 on a Pentium 2.67 GHz with 1.00 GB of RAM. 

Table 3 shows the encoding size of the two implementations, where the encoding size is 
characterized by the number of variables and the number of constraints in the formulation. 
Both the encoding size before and after applying ILOG CPLEX presolve is given. Presolve is 
a problem reduction technique (Brearley, Mitra, & Williams, 1975) that helps most linear 
programming problems by simplifying, reducing and eliminating redundancies. In short, 
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State change model Optiplan 





Before presolve 


After presolve 


Before presolve 


After 


presolve 


Problem 


#Var. 


#Cons. 


#Var. 


#Cons. 


#Var. 


#Cons. 


#Var. 


#Cons. 


bw-sussman 


486 


878 


196 


347 


407 


593 


105 


143 


bw- 12 step 


3900 


7372 


1663 


3105 


3534 


4998 


868 


1025 


bw-large-a 


6084 


11628 


2645 


5022 


5639 


8690 


1800 


2096 


att-logO 


1932 


3175 


25 


35 


117 


149 








log-easy 


24921 


41457 


1348 


2168 


2534 


3029 


437 


592 


log-a 


50259 


85324 


3654 


6168 


5746 


7480 


1479 


2313 



Table 2: Encoding size of the original state change formulation and Optiplan before and 
after ILOG CPLEX presolve. #Var. and #Cons. give the number of variables 
and constraints respectively. 



Problem 




State change model 






Optiplan 




#Var. 


#Cons. 


#Nodes 


Time 


#Var. 


#Cons. 


#Nodes 


Time 


bw-sussman 


196 


347 





0.01 


105 


143 





0.01 


bw-12step 


1663 


3105 


19 


4.28 


868 


1025 


37 


1.65 


bw-large-a 


2645 


5022 


2 


8.45 


1800 


2096 





0.72 


bw-large-b 


6331 


12053 


14 


581.92 


4780 


5454 


10 


72.58 


att-logO 


25 


35 





0.01 











0.01 


att-logl 


114 


164 





0.03 


29 


35 





0.01 


att-log2 


249 


371 


10 


0.07 


81 


99 





0.01 


att-log3 


2151 


3686 


15 


0.64 


181 


228 





0.03 


att-log4 


2147 


3676 


12 


0.71 


360 


507 





0.04 


att-loga 


2915 


4968 


975 


173.56 


1479 


2312 


19 


2.71 


rocket-a 


1532 


2653 


517 


32.44 


991 


1644 


78 


5.48 


rocket-b 


1610 


2787 


191 


9.90 


1071 


1788 


24 


3.12 


log-easy 


1348 


2168 


43 


0.96 


437 


592 





0.04 


log-a 


3654 


6168 


600 


145.31 


1479 


2313 


19 


2.66 


log-b 


4255 


6989 


325 


96.47 


1718 


2620 


187 


14.06 


log-c 


5457 


9111 


970 


771.36 


2413 


3784 


37 


16.07 



Table 3: Performance and encoding size of the original state change formulation and Op- 
tiplan. #Var. and #Cons. give the number of variables and constraints after 
ILOG CPLEX presolve, and #Nodes give the number of nodes explored during 
branch-and-bound before finding the first feasible solution. 
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presolve tries to remove redundant constraints and fixed variables from the formulation, 
and aggregate (substitute out) variables if possible. 

From the encoding size before presolve, which is the actual encoding size of the problem, 
we can see how significant the use of planning graphs is. Optiplan, which instantiates 
only those fluents and actions that are reachable and relevant through planning graph 
analysis, produces encodings that in some cases are over one order of magnitude smaller than 
the encodings produced by the original state change model, which instantiates all ground 
fluents and actions. Although the difference in the encoding size reduces substantially 
after applying presolve, planning graph analysis still finds redundancies that presolve fails 
to detect. Consequently, the encodings produced by Optiplan are still smaller than the 
encodings that are produced by the original state change model. 

The performance (and the encoding size after presolve) of Optiplan and the original 
state change model are given in Table 3. Performance is measured by the time to find the 
first feasible solution. The results show the overall effectiveness of using planning graph 
analysis. For all problems Optiplan not only generates smaller encodings it also performs 
better than the encodings generated by the state change model. 

5.1 IPC Results 

Optiplan participated in the propositional domains of the optimal track in the IPC 2004. In 
this track, planners could either minimize the number of actions, like BFHSP and Semsyn; 
minimize makespan, like CPT, HSP*a, Optiplan, Satplan04, and TP-4; or minimize some 
other metric. 

The IPC results of the makespan optimal planners are given in Figure 2. All results were 
evaluated by the competition organizers by looking at the runtime and plan quality graphs. 
Also, all planners were compared to each other by estimating their asymptotic runtime and 
by analyzing their solution quality performance. Out of the seven competition domains, 
Optiplan was judged second best in four of them. This is quite remarkable because integer 
programming has hitherto not been considered competitive in planning. 

Optiplan reached second place in the Optical Telegraph and the Philosopher domains. 
In these domains Optiplan is about one order of magnitude slower than Satplan04, but it 
clearly outperforms all other participating planners. In the Pipesworld Tankage domain, 
Optiplan was awarded second place together with Satplan04, and in the Satellite domain 
Optiplan, CPT, and Semsyn all tied for second place. In the other domains Optiplan did 
not perform too well. In the Airport domain, Optiplan solves the first 17 problems and 
problem 19, but it takes the most time to do so. For the Pipesworld Notankage and the 
PSR domains, Optiplan not only is the slowest it also solves the fewest number of problems 
among the participating planners. 

In looking at the domains and problems where Optiplan has difficulty scaling, we notice 
that these are problems that lead to very large IP encodings. Since the size of the encoding is 
a function of plan length, Optiplan often fails to solve problems that have long solution plans. 
One way to resolve this issue is to de-link the encoding size from solution length, which is 
what we have done in some of our recent work (van den Briel, Vossen, & Kambhampati, 
2005). In fact, in the year following the IPC4 we developed novel IP encodings that (1) 
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model transitions in the individual fluents as separate but loosely coupled network flow 
problems, and that (2) control the encoding length by generalizing the notion of parallelism. 

6. Conclusions 

The Optiplan planning system performs significantly better than the original state change 
model by Vossen and his colleagues (1999). It performed respectably at the IPC4, but still 
lags behind SAT- and CSP-based planners, like Blackbox(Chaff), Satplan04(Siege), and 
GP-CSP. We believe, however, that this performance gap is not because IP techniques are 
inferior to SAT and CSP, but rather a reflection of the types of IP formulations that have 
been tried so far. Specifically, the encodings that have been tried until now have not been 
tailored to the strengths of the IP solvers (Chandru k, Hooker, 1999). 

Our experience with Optiplan has encouraged us to continue working on improved IP 
formulations for AI planning. In our recent work (van den Briel, Vossen, &; Kambhampati, 
2005) we model fluents as loosely coupled network flow problems and control the encoding 
length by generalizing the notion of parallelism. The resulting IP encodings are solved 
within a branch-and-cut algorithm and yield impressive results. Also, this new approach 
has been shown to be highly competitive with the state-of-the-art SAT-based planners. 
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